Subject: Introduction and Queries

From: [email-masked] (Paul Brittain)
Date: Wed, 25 Aug 93 16:46:41 BST

Since joining the DLSw siglets a few weeks ago, I have been wading through the
mountains of mail generated so far in search of the answers to several areas
of the RFC that are unclear to me.

If any of these points have been discussed before, please just point me in the
direction of the appropriate mail messages.  I have tried to check for such
mail, but there is a limit to the level of concentration I can maintain through
1 Mb of mail!

First however, a brief introduction.

My name is Paul Brittain.  I work for Data Connection Limited and have been
looking at the RFC and SIG traffic to date with a view to identifying 'grey
areas' that are not specified sufficiently tightly and hence may lead to
interoperation problems with products from different vendors.

All of the issues I have identified so far are in the area of ciruit setup, so
I have addressed this note to the connection siglet.  If anyone thinks the
issues should be referred to other siglets, please feel free to do so.

Some or all of these issues may already be addressed by the 6611, hence I would
be particularly interested in comments on these issues from the IBM people
monitoring this siglet.

1) MANAGEMENT OF TOPOLOGY INFORMATION
=====================================

I have three questions about the following passage under section 4.2.2.1
"DISCONNECTED state" of RFC 1434.

    "It is assumed that each DLS will build a set of topology tables giving
     the identity of each DLS that can reach a specific MAC address or a
     specific NETBIOS name."

a) Later on in this section it states that the CANUREACH will be sent to only
those Data Link Switches known to be able to reach the MAC address.

This would mean that if, say, the local DLS topology table says that MAC
address X is reachable by DLS A, and, unknown to the local DLS, X is
disconnected from A and attached to a token ring reachable by DLS B (and not
A), the local DLS will never be able to establish a circuit with X again, even
if DLS B is known to it.  If this seems unlikely, consider the case of portable
machines that are regularly moved between offices (such as the one I'm typing
this on at the moment!)

Is it the intention that if a DLS does not get an answer to a CANUREACH
from the remote DLS listed in its topology table, it should retry the
CANUREACH to entire DLS mesh?

b) Why are multiple entries supposed to be maintained for each MAC address?
Why not maintain only an entry for the last DLS known to be able to reach
the MAC address?

c) If multiple entries are to be maintained, what rationale should be
used for knowing when to delete 'old' entries in the topology tables?
Potentially, these tables might contain entries for ALL known DLSs for a
particular MAC, which defeats the object of maintaining the topology table
(since CANUREACH messages would then be sent to everyone anyway).

I recognize that (c) may be an area where vendors will seek to achieve some
differentiation for their product, but (a) and (b) ought to be addressed in a
common way for all vendors.

2) MULTIPLE CIRCUITS FOR THE SAME DATA LINK ID
==============================================

A question about the following passage from section 4.2.2.2 "RESOLVE_PENDING
state" of the RFC.

     "The ICANREACH should be returned to all DLSs that had sent a
      CANUREACH message."

Is this "all DLSs that had sent a CANUREACH for the same Data Link ID"?

If this is so, are multiple circuits for the same Data Link ID to be set up
(only one of which is ever used)?

Or is one circuit set up, and it's the origin DLS that first gets its REACH_ACK
back to the target that gets the circuit?

Or, in a similar vein to my first query, is it really necessary to return the
ICANREACH to all the DLSs when we will only be setting up one end-to-end LLC2
connection?

3) UNSUCCESSFUL CANUREACH ATTEMPTS
==================================

When a DLS issues CANUREACH to other known DLSs, it must maintain a control
block for this circuit establishment attempt, containing, if nothing else,
the information that it has the CANUREACH outstanding so that retried TEST
commands are ignored.  Preferably, this control block would also contain the
RIF so that it can return the TEST response to the originator.

Each time a CANUREACH is issued to known DLSs, a new control block must be
created.  Even assuming that these control blocks are 'converted' to circuit
control blocks as circuits are established,  an ever increasing amount of
memory will be taken up by control blocks for unsuccessful CANUREACH attempts.

A solution to this would be to timeout the CANUREACH control blocks,
assuming the attempt to have failed after a certain time period (as,
presumably, there comes a point when we have to allow further TEST commands to
generate CANUREACH messages).

Does this break the protocol?  Consider the following.

        -       Origin sends CANUREACH to target.
        -       After a while, origin times out circuit set up attempt and
                destroys control block.
        -       Target sends ICANREACH to target.
        -       Origin discards ICANREACH (no control block).
        -       Target never gets a REACH_ACK.

Although the RFC specifies what to do if a REACH_ACK is lost, this is a
different case as there is no circuit and there will be no further messages.
The Target would be left with a circuit in CIRCUIT_PENDING state forever.

One way out of this problem would be not to keep any information about
CANUREACH requests sent out (indeed, is this what is implied by the 6611
issuing TEST commands instead of responses?).  However this does not fit with
the requirement already stated in the SIG that TEST retries are not sent out to
the DLS mesh (hence you have to keep some data in order to filter out such
retries).

Failure to keep the RIF from a TEST command that lead to a CUR also requires an
additional state in the FSMs to cover the wait for a response to the TEST
command issued after an ICANREACH message is received.  During this time, any
data received from the Target DLS on that circuit has nowhere to go because no
RIF has been established yet.

4) RETRIES OF NETBIOS MESSAGES
==============================

It has been stated that TEST commands are retried by the recipient
of a CANUREACH message as appropriate for the LAN environment beneath.  Further
TEST commands received by the origin DLS do not cause further CANUREACH
messages until a timeout period has expired.

Is the same true of Netbios Name Query commands issued as a result of an
incoming NETBIOS_NQ message? Or does the origin DLS send a NETBIOS_NQ for
every Netbios Name Query received?

This issue also applies to Add Name Query requests.

5)  SIMULTANEOUS CANUREACH MESSAGES
===================================

If two CANUREACH messages cross between two DLSs, both trying to set up a
circuit between the same MAC/SAP pair, we either get two circuits set up or
confusion over who is the originator of the circuit.

I'll explain that in a bit more detail.

-  FRED broadcasts a TEST to BILL, which is picked up by DLSA and sent as a
   CUR to DLSB (+ other DLSs that we'll ignore).

-  At the same time BILL issues a TEST to FRED which is picked up by DLSB and
   sent as a CUR to DLSA.

-  On receiving the CUR, DLSB issues a TEST to BILL, gets a response, allocates
   a circuit ID and issues an ICR to DLSA.

-  Similarly, DLSA allocates a circuit ID and issues an ICR to DLSB.

-  DLSB (say) then receive the ICR for the same data link ID as the one it is
   expecting a REACH_ACK for.  Does it now allocate another circuit ID giving
   us two circuits, or match the ICR with the original circuit?  If the latter,
   who is the origin DLS? (remember that DLSA will be going through the same
   processing)

I don't think allowing two circuits is sensible because that gives problems if
DLSA and DLSB both think they are the origin DLS.  Also, when they come to
set up the LLC2 connection, both DLSA and DLSB could end up (illegally) asking
LLC2 to set up the same Link Station twice over.

However if we try to merge the two connection attempts we have several
problems:

-       the RFC specifies no algorithm for deciding which circuit to drop
-       the state machine does not allow for merging of circuits in this
        manner.

One possible solution that almost solves this problem is to regard the Origin
and Target DLS roles as existing on a 'per message' basis rather than fixed per
circuit.  The Frame Direction field then serves only to identify which set of
ID fields to look at in the SSP header.  A DLS can then use the receipt of an
ICR when expecting a REACH_ACK to merge the two circuit IDs (sending a
REACH_ACK back specifying the circuit ID it specified on its own ICR sent
previously).  However this does not solve who issues the CONTACT and CONTACTED
SSP messages.

This all seems to be getting over-complicated for a simple crossover case.
Have I missed something in the RFC?

Paul Brittain
Data Connection Limited
+44 244 313440